1. Prior Art
In “conventional” telephony (public switched telephone network, PSTN), telephony operators establish bilateral agreements to extend the global coverage of the telephone service. The level of coverage achieved depends essentially on the number of agreements made. In outline, it can be considered that two categories of telecommunications operator are in existence: local and/or national operators, and global operators. The major global operators make a large number of agreements and can thus reach most existing destinations. Local operators make only a small number of agreements, including only one or two with major operators. Thus, a incumbent national operator in a developing country will make agreements with other national operators and one or two agreements with global operators in order to deliver calls to the rest of the world.
At present, most operators are migrating their PSTN networks to solutions and infrastructures that are based on the IP network. To accompany the deployment of VoIP services, the Internet engineering task force (IETF) has undertaken a large amount of standardization work. Several protocols have been specified, amongst which mention can be made of session initiation protocol (SIP), session description protocol (SDP), real-time transfer protocol (RTP), real-time transfer control protocol (RTCP), multimedia gateway control protocol (MGCP), session advertisement protocol (SAP), and telephony routing over IP (TRIP, RFC3219). These protocols satisfy different requirements and in particular they incorporate call signaling and control, the exchange and control of media streams, and the exchange of call routing information.
For more information about the TRIP protocol, reference can be made to standardization document RFC3219. It is particularly in the context of that RFC3219 specification that an embodiment of the present invention lies.
TRIP enables interconnected ITADs to exchange all of the destinations they can reach, thereby facilitating the selection of the gateways that are the most appropriate for delivering IP telephony traffic to the PSTN. The TRIP protocol is implemented by location servers (LS) that propagate TRIP routes containing attributes that serve to describe the routes in question. The use of this particular protocol is independent of the type of signaling protocol deployed for actually setting up calls. The TRIP protocol can be used together with SIP, H.323, or any other signaling protocol.
Each LS maintains a local routing database known as the telephony routing information database (TRIB). This routing database is fed with advertisements received from neighboring LSes (from another telephony domain, for example). The operation of the TRIP protocol is similar to that of the BGP protocol. Advertisements between neighboring LSes are made in the form of route update messages, referred to simply as update messages. Such a message is defined by the TRIP protocol and it is exchanged between LSes in order to inform an LS in the same domain or in a neighboring domain about routes that are available.
Activation of the TRIP protocol between various ITADs is described with reference to FIG. 1 (for reasons of simplicity, the term “domain” is also used to denote an ITAD), each ITAD being administered by a single telephony operator. Each of these operators has one or more LSes and one or more proxy servers (PS). Each LS maintains a routing database that it feeds with advertisements received from its neighbors (situated in other domains) and from LSes in its own domain. These advertisements are updated and forwarded to other neighbors when agreements permit this. Each PS is responsible for setting up calls and processing signaling messages received from clients or from other PSes. In FIG. 1, only the LSes are shown.
Thus, ITAD4 14, for example, updates the advertisements received from ITAD5 15 and forwards them to ITAD3 13. It should be observed that an ITAD is not necessarily deployed on a single IP transfer domain, also referred to an AS.
From the routing point of view, an LS handles three types of route:                external routes, received from LSes situated in neighboring ITADs;        internal routes, received from LSes situated in the same ITAD; and        local routes, configured locally in each LS for injection into TRIP processes. This operation is performed either by static configuration or by redistributing information coming from other routing protocols.        
Thus, four types of TRIB are managed by an LS, as is shown in FIG. 2. These tables exist in a single LS, and the relationship between the tables are described with reference to FIG. 2.                Adj-TRIBs-In 22 (adjacent TRIB in): stores routing information conveyed by update messages. This routing information, also referred to as “routes”, constitutes the input to a route selection process 21 (decision process). A given LS maintains an adjacent TRIB-In table 22 for each neighboring LS in which it stores all of the route advertisements received from an adjacent LS;        Ext-TRIB 24 (external TRIB): a single external TRIB table is maintained by an LS. This table contains the results of a route selection process applied to external routes 25 (Adj-TRIBs-IN) and local routes 26. Prior art techniques enable only one route to be selected per destination;        Loc-TRIB 20 (local TRIB): this table contains the local routes that result from applying routing policies that are local to each LS; and        Adj-TRIBs-Out 23 (adjacent TRIB out): these are the routes that the local LS will advertise to its peers.        
At this stage, TRIP enables a single unique route to be stored per destination in the local TRIB. This route is the route that is advertised to the peers of a given LS, i.e. to the neighboring LSes (which may be in the same ITAD, or in a different ITAD), providing an agreement exists between them). To do this, TRIP implements a route selection process to determine the best route for storing in its local TRIB. If a route to the destination already exists, then the selection process is invoked. If the new route is selected by the process, the new route replaces the old route in the local TRIB.
2. Drawbacks of the Prior Art
A drawback of that prior art technique is the absence of means for managing the resilience of routes advertised by the TRIP protocol or means for managing load sharing between a plurality of TRIP routes serving the same destination.
In the present technique, if a route exists, a single unique route is advertised, for a given destination. Unfortunately, in the context of VoIP/ToIP, it is recommended to have a (dynamic) backup route or alternative routes for reasons of load sharing and for emergency use in order to ensure that the service has high availability, close to five nines, other than static routes.
The present state of the art does not enable such a backup or load sharing service to be provided because the local telephony routing table does not store any alternative routes to a given destination.